A flaw was discovered in Podman where it incorrectly allows containers when created to overwrite existing files in volumes, even if they are mounted as read-only. When a user runs a malicious container or a container based on a malicious image with an attached volume that is used for the first time, it is possible to trigger the flaw and overwrite files in the volume.

'podman cp' will resolve a carefully crafted symlink in host-filesystem space, yielding unexpected results when cp'ing from container to host. An attacker could create a container image containing particular symlinks that, when copied by a victim user to the host filesystem, may overwrite existing files with others from the host.

Upstream Issue: https://github.com/containers/libpod/issues/3829

A path traversal vulnerability has been discovered in podman before version 1.4.0 in the way it handles symlinks inside containers. An attacker who has compromised an existing container can cause arbitrary files on the host filesystem to be read/written when an administrator tries to copy a file from/to the container.

The containers/image library used by container tools; Podman, Builah, and Skopeo in Red Hat Enterprise Linux 8, and CRI-O in OpenShift Container Platform does not enforce TLS connections to the container registry authorization service [1]. An attacker could use this vulnerability launch a MiTM attack, and steal login credentials, or bearer tokens.

Upstream issue:

https://github.com/containers/image/issues/654

Upstream patch:

https://github.com/containers/image/pull/669

[1] https://docs.docker.com/registry/spec/auth/token/

It has been discovered that podman before version 0.6.1 does not drop capabilities when executing a container as a non-root user. This results in unnecessary privileges being granted to the container.